<table class="configuration table table-bordered">
    <thead>
        <tr>
            <th class="text-left" style="width: 20%">Key</th>
            <th class="text-left" style="width: 15%">Default</th>
            <th class="text-left" style="width: 10%">Type</th>
            <th class="text-left" style="width: 55%">Description</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><h5>execution.buffer-timeout</h5></td>
            <td style="word-wrap: break-word;">100 ms</td>
            <td>Duration</td>
            <td>The maximum time frequency (milliseconds) for the flushing of the output buffers. By default the output buffers flush frequently to provide low latency and to aid smooth developer experience. Setting the parameter can result in three logical modes:<ul><li>A positive value triggers flushing periodically by that interval</li><li>0 triggers flushing after every record thus minimizing latency</li><li>-1 ms triggers flushing only when the output buffer is full thus maximizing throughput</li></ul></td>
        </tr>
        <tr>
            <td><h5>execution.checkpointing.snapshot-compression</h5></td>
            <td style="word-wrap: break-word;">false</td>
            <td>Boolean</td>
            <td>Tells if we should use compression for the state snapshot data or not</td>
        </tr>
        <tr>
            <td><h5>execution.runtime-mode</h5></td>
            <td style="word-wrap: break-word;">STREAMING</td>
            <td><p>Enum</p></td>
            <td>Runtime execution mode of DataStream programs. Among other things, this controls task scheduling, network shuffle behavior, and time semantics.<br /><br />Possible values:<ul><li>"STREAMING"</li><li>"BATCH"</li><li>"AUTOMATIC"</li></ul></td>
        </tr>
        <tr>
            <td><h5>execution.shuffle-mode</h5></td>
            <td style="word-wrap: break-word;">AUTOMATIC</td>
            <td><p>Enum</p></td>
            <td>Mode that defines how data is exchanged between tasks if the shuffling behavior has not been set explicitly for an individual exchange. The shuffle mode depends on the configured 'execution.runtime-mode' and is only relevant for batch executions on bounded streams.<br />In streaming mode, upstream and downstream tasks run simultaneously to achieve low latency. An exchange is always pipelined (i.e. a result record is immediately sent to and processed by the downstream task). Thus, the receiver back-pressures the sender.<br />In batch mode, upstream and downstream tasks can run in stages. Blocking exchanges persist records to some storage. Downstream tasks then fetch these records after the upstream tasks finished. Such an exchange reduces the resources required to execute the job as it does not need to run upstream and downstream tasks simultaneously.<br /><br />Possible values:<ul><li>"ALL_EXCHANGES_PIPELINED": Upstream and downstream tasks run simultaneously. This leads to lower latency and more evenly distributed (but higher) resource usage across tasks in batch mode. This is the only supported shuffle behavior in streaming mode.</li><li>"ALL_EXCHANGES_BLOCKING": Upstream and downstream tasks run subsequently. This reduces the resource usage in batch mode as downstream tasks are started after upstream tasks finished. This shuffle behavior is not supported in streaming mode.</li><li>"AUTOMATIC": The framework chooses an appropriate shuffle behavior based on the runtime mode and slot assignment.</li></ul></td>
        </tr>
    </tbody>
</table>
